IBIS Macromodel Task Group Meeting date:27 July 2021 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Rui Yang Luminous Computing David Banas Marvell Steve Parker Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send BIRD213.1 draft 2 to ATM for people to review. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 20th meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: BIRD211.3 draft2: Fangyi shared the draft. Ambrish said he had read about half of it, and he had comments. Ambrish said, the Definition of the Issue section states that, "The current Redriver statistical simulation flow is known to have the following issues:" However, three issues are then listed, and the third one affects time domain simulations not statistical simulations. Arpad and Fangyi suggested removing the word "statistical" from the introductory sentence. Radek agreed, and Ambrish said this would resolve the problem. Top of Page 4: Ambrish said the "(column 1)" was not needed in item 1. The group redid the wording of item 1 for clarity. Ambrish said only the first sentence of item 3 should remain. He said the last two sentences were just attempting to summarize information that is already provided in the Usage Rules of Tx_Impulse_Input. Bob said that references to page numbers should be removed, as this BIRD will be relative to 7.1, and we don't yet have that finalized. In addition, he said the page numbers weren't necessary since the BIRD describes where things should be inserted relative to existing sections. page 6: In the system simulation figure near the top of the page, Ambrish noted that the word Channel should not appear at the far left of the figure. Fangyi added a note to remove the left-most "Channel" from the figure. page 7: Normal (non-repeater) flow descriptions: Ambrish asked whether the changes in the statistical and time domain flows for the normal channel had actually amounted to any changes in results. He said that step 2 in both the statistical and time domain flows, which deals with the values of Tx_Impulse_Input, isn't adding anything for the normal flow. Fangyi agreed that for a normal flow the results don't change. Arpad said we had needed to apply the new parameter description to the normal flow to explain how it affects old models. Curtis said we had decided to treat the terminal Tx and the Redriver Tx in exactly the same way. Ambrish said all the new steps and discussion of Tx_Impulse_Input amount to nothing in the normal flow. Ambrish said that nothing really changes in the normal flow. He said we should tell EDA tools to simply ignore the new Tx_Impulse_Input parameter for a terminal Tx, as it doesn't add any value. Fangyi agreed that we could do that. He said we already state that if the parameter is not present, the default is assumed to be "Downstream". Fangyi added a note to the draft indicating that we should keep the original flow and add a statement about the new parameter being irrelevant to the normal flow. Ambrish said he would prefer not to change any language in the specification if we don't have to. page 8: Normal time-domain flow Ambrish said steps 3 through 5 contain discussion about the ways an EDA tool may determine the model's equalization response if GetWave_Exists is false. He noted that the 7.0 specification explicitly stated the conditions under which double- counting could be an issue and deconvolution might be needed (if the Tx's GetWave_Exists is True, and the Rx's GetWave_Exists is false, then you might double count the effects of the Tx since they are contained in the input and output of the Rx's AMI_Init and would also be in the Tx GetWave's output). He said the new language mentions determining the Tx model's equalization response, but we don't have a problem generating results at the Rx if the Tx is Init-Only (GetWave_Exists is false). The new language also fails to explicitly describe the actual problem scenario. Ambrish said we should not change the normal flow at all. We should only add the additional statements about how the tool can use the "unit impulse response" dummy aggressor column to determine the filter's response. He noted that even this is only necessary for the Rx. There is never a need to for the tool to determine the Tx filter's response to get the right answer at the Rx. Fangyi agreed that we could revert to the 7.0 descriptions for the normal flow. He said the Redriver flows that need the new steps and parameters have all of the steps independently stated and do not rely on references to the normal flow. He noted that EDA tools could always safely utilize the unit impulse response dummy crosstalk column with Tx models, because no Tx model would optimize based on crosstalk columns, as no physical Tx device would be aware of its aggressing effects onto others. Arpad asked if anyone objected to adopting Ambrish's suggestions. There were no objections. Fangyi agreed to revise the BIRD draft accordingly. PAMn BIRD213 discussion: Walter briefly reviewed the fundamentals of the BIRD. He said the goal was to avoid the need for a new BIRD and new separate parameters for each new modulation level, n, we wanted to support. The proposal defines Format Table parameters for thresholds, offsets, etc., and these can be of varying lengths to support different modulations. Walter noted that the major debate last week had been about PAM_Mapping_Name and PAM_Mapping_Table. He said Ambrish had suggested that we remove everything related to mapping and assume the EDA tool is responsible for knowing what to do for each type of interface. Ambrish agreed with this summary. Walter said he had no problem with the suggestion, and he proposed that we consider a motion at the next meeting to remove the mapping information altogether. Arpad asked whether we could create an Out parameter so the model could tell the EDA tool what mapping to use. Walter said the model only knows that it has n levels and likely doesn't know about the mapping. Fangyi asked whether this BIRD limited the model to supporting one value of n. Walter said the parameters were allowed to be Usage Out, so the model could return dynamically sized tables for different values of n. The number of rows in a table is dynamic, but the number of columns in each row is not. So, the model could return n rows, each with a single column value. Fangyi suggested the specification should mandate that the number of rows in the Output table(s) match the value of n. Ambrish asked whether the threshold parameter should be required. He said EDA tools could have ways to figure out thresholds themselves. - Randy: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Walter to send BIRD213.1 draft 3 to ATM for people to review. AR: Fangyi to create BIRD211.3 draft 3 based on discussion in today's meeting. ------------- Next meeting: 03 August 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives